DOM-basiertes Cross-Site Scripting im Web: Reise in ein unerforschtes Land

Cross-site Scripting (XSS) ist eine weit verbreitete Verwundbarkeitsklasse in Web-Anwendungen und kann sowohl von server-seitigem als auch von clientseitigem Code verursacht werden. Allerdings wird XSS primär als ein server-seitiges Problem wahrgenommen, motiviert durch das Offenlegen von zahlreichen entsprechenden XSS-Schwächen. In den letzten Jahren jedoch kann eine zunehmende Verlagerung von Anwendungslogik in den Browser beobachtet werden eine Entwicklung die im Rahmen des sogenannten Web 2.0 begonnen hat. Dies legt die Vermutung nahe, dass auch client-seitiges XSS an Bedeutung gewinnen könnte. In diesem Beitrag stellen wir eine umfassende Studie vor, in der wir, mittels eines voll-automatisierten Ansatzes, die führenden 5000 Webseiten des Alexa Indexes auf DOM-basiertes XSS untersucht haben. Im Rahmen dieser Studie, konnten wir 6.167 derartige Verwundbarkeiten identifizieren, die sich auf 480 der untersuchten Anwendungen verteilen. 1 Einleitung und Motivation Der Begriff Cross-Site Scripting (XSS) beschreibt eine Klasse von Injektionsangriffen, bei der es dem Angreifer möglich ist, eigenen HTMLund JavaScript-Code in die Seiten der angegriffenen Anwendung einzuschleusen. In ihrem Ranking der kritischsten Sicherheitsprobleme von Web-Anwendungen platziert das Open Web Application Security Project (OWASP) XSS auf Platz drei [Ope13] und das Sicherheitsunternehmen Whitehat Security berichtete in der diesjährigen Ausgabe ihres Sicherheitsreports, dass 43% aller Schwachstellen in Web-Applikationen in die Kategorie Cross-Site Scripting einzuordnen waren [Whi13a]. In der allgemeinen Literatur wird XSS meist als server-seitiges Problem behandelt [Eck04]. Dementsprechend beschränken sich die etablierten Gegenmaßnahmen meist auf server-seitige Filterung der potenziell unvertrauenswürdigen Nutzereingaben und der Bereinigung des finalen HTML/JavaScript-Codes über Output Sanitization, bevor dieser an den Web-Browser geschickt wird. Derweil führt die Unterklasse des DOM-basierten XSS [Kle05], in dem die XSS-Lücke durch rein client-seitigen JavaScript-Code verursacht wird, ein Schattendasein, bedingt durch eine deutlich kleinere Angriffsoberfläche: Sowohl die Menge der client-seitigen ∗Technische Grundlage dieses Beitrags ist die englischsprachige Verffentlichung “25 Million Flows Later Large-scale Detection of DOM-based XSS” [LSJ13]. Im Vergleich bietet dieser Beitrag eine erweiterte Analyse der gesammelten Daten (siehe Abschnitt 5), die in dieser Form im Originalartikel fehlt. Quellen von Daten, die vom Angreifer kontrolliert werden können, wie auch die Menge an potenziell unsicheren Sprachkonstrukten, die zu XSS Lücken führen, sind ungleich kleiner als auf der Serverseite. Bis dato gab daher noch keine Studie, welche das Vorkommen dieser Art von Schwachstellen systematisch untersucht hat. Ziel der Arbeit war es, diesen recht unerforschten Schwachstellentyp strukturiert zu erforschen und mögliche Muster in den Verwundbarkeiten aufzudecken. Um eine groß angelegte Untersuchung dieser Art zu ermöglichen, wurden im Rahmen der Arbeit mehrere Komponenten zur automatisierten Analyse von Webseiten entwickelt. Anschließend wurde diese Infrastruktur genutzt, um die Alexa Top 5000 Webseiten in einem Shallow Crawl zu untersuchen. Insgesamt konnten im Rahmen dieser Untersuchung auf 480 der Alexa Top 5000 Webseiten Schwachstellen dieser Art festgestellt werden. DOM-basiertes XSS ist also eine relevante Schwachstelle im Web von heute. Dieses Papier gliedert sich wie folgt: In Abschnitt 2 werden die technischen Hintergründe zur Same-Origin Policy, Cross-Site Scripting sowie im speziellen DOM-basiertem CrossSite Scripting vorgestellt. Abschnitt 3 stellt dann die Kern-Komponenten des von uns entwickelten Systems vor, mit dem die Untersuchungen durchgeführt wurden. Im Anschluss werden in Abschnitt 4 die Vorgehensweise und die Ergebnisse der durchgeführten empirischen Studie diskutiert. Abschnitt 5 analysiert dann die Ergebnisse der Studie und zeigt die gewonnenen Erkenntnisse auf. Zuletzt werden verwandte Arbeiten erläutert (Abschnitt 6) und abschließend der wissenschaftliche Beitrag der Arbeit zusammengefasst (Abschnitt 7). 2 Technischer Hintergrund Im Folgenden werden die Grundlagen zur Same-Origin Policy (SOP) und Cross-Site Scripting als Umgehung der SOP gelegt. Im Anschluss wird speziell auf DOM-basiertes CrossSite Scripting eingegangen und die Kontext-Sensitivität von Cross-Site Scripting erläutert. 2.1 Die Same-Origin Policy und Cross-Site Scripting Das grundlegendste, in Browser implementierte Prinzip zur Abgrenzung von Applikation voneinander ist die Same-Origin Policy (SOP) [Bar09]. Die SOP schützt Resourcen vor Fremdzugriff und erlaubt den Zugriff nur dann, wenn der Origin der beiden interagierenden Resourcen übereinstimmt. Der Origin ist dabei über die Kombination aus Protokoll, Domain und Port definiert. Cross-Site Scripting beschreibt eine Reihe von Angriffen, die auf das Einschleusen von Script-Code abzielt, um die Same-Origin Policy zu umgehen. Gelingt es einem Angreifer, seinen eigenen JavaScript-Code durch eine Schwachstelle in eine Applikation einzuschleusen, wird dieser Code im Kontext der Applikation im Browser des Opfers ausgeführt. Konkret bedeutet dies, dass der Angreifer damit im Namen des Benutzers mit der Applikation interagieren kann. Das Schadpotenzial solcher Angriffe zeigt das aktuelle Beispiel der Seite ubuntuforums.org, von der 1,82 Millionen Benutzerdaten durch Ausnutzen einer Cross-Site Scripting-Schwachstelle gestohlen werden konnten [Whi13b]. Die in der Literatur erwähnten, altbekannten Arten von Cross-Site Scripting sind dabei 54 DOM-basiertes Cross-Site Scripting im Web: Reise in ein unerforschtes Land